System and Method for Producing Transaction Level Detail Based on a Card Spend Transaction

ABSTRACT

A system is disclosed for providing charge transaction detail comprising financial account spend transactions. Through a mapping of a merchant&#39;s item codes with an issuer&#39;s item codes, the system provides clients with a more descriptive report based on any one or more transaction instruments associated with the financial account. The charge transaction detail can include anything related to charge or credit card transactions including hotel reservation detail, corporate card detail and corporate purchasing card detail. The transaction detail can be captured from many sources and can include third party data. The clients can use a web application and web page to access the account data and create report views of the information. The system can also includes a create a report capability, which allows users to add filters and data elements to an existing report format and create a report specific to their needs and data.

REFERENCE TO RELATED APPLICATION

This application is a continuation-in-part of, and claims priority to, U.S. patent application Ser. No. 10/608,764, filed on Jun. 27, 2003, which itself claim priority to U.S. Provisional Patent Application Ser. No. 60/468,495, filed on May 6, 2003, the entire contents of which are incorporated herein by reference.

FIELD OF INVENTION

The present invention generally relates to providing data to customers on-line, and more particularly, to a system and method to enable charge card holders and others with a certain web application to access charge card detail on-line via a network and view transaction level detail relating to travel expenses, such as hotel expenditures.

BACKGROUND OF THE INVENTION

Previous options for clients to view and receive certain reports (e.g., Management Information Reports) were, for example, to receive the reports on paper each month, receive the reports as a data file, or receive data on diskette and/or a CD which was loaded into PC based applications for viewing and reporting. However, these delivery mechanisms were slow (in some cases 90-days after the close of a quarter) and costly. As such, a need existed for an on-line capability to replace or enhance the distribution options. However, on-line tools, for example, were not able to be sufficiently developed because of the complexity of data capture, conditioning from multiple sources, the excessive volume of transaction level detail needed to provide the full functionality required and the lack of technology options to create solutions.

Moreover, previous reports and/or transaction card billing statements provided limited information regarding the nature of the transaction card spend transaction. This limited information may include, for example, an amount billed against a transaction card on a given date for a specific hotel in a specific city. However, clients were particularly unsatisfied with the amount of hotel folio data classified in “Other” and “Miscellaneous” categories, particularly because existing systems were unable to present hotel folio data at a detailed level. For example, a hotel charge may appear on a billing statement as a single line item in the amount of $1,360. However, it was not clear how much of that sum is attributed to room charges, applicable taxes, hotel restaurant and room service charges, business services (e.g., faxing, computer services, photocopying), parking, ground transportation, and the like. Moreover, while some hotels may employ more descriptive item codes, others are not so descriptive. As such, a need exists for a capability to classify hotel folio line item data into comprehensive and descriptive item types for the hotel spend.

SUMMARY OF THE INVENTION

An apparatus and method of the present invention provides on-line financial account spend data to users. Through item code mapping, the present invention enables an account issuer to compile and present hotel spend transactions with descriptive item codes, specifying previously unknown details regarding general spend transactions. In response to an on-line request from a client for hotel folio information, the method and apparatus retrieve data from multiple sources and conditions the data according to pre-configured item code to item code mappings to compile the hotel folio data. The hotel folio data is then provided to the client via any means known in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, wherein like reference numerals represent like elements, are incorporated in and constitute a part of this specification and, together with the description, explain the advantages and principles of the invention. In the drawings,

FIG. 1 is a schematic diagram of a system for providing on-line account data in accordance with exemplary embodiments of the present invention;

FIG. 2 is a schematic diagram of components of computers and servers used in the system in accordance with exemplary embodiments of the present invention;

FIG. 3 is a flow chart of an exemplary method to provide on-line account data in accordance with exemplary embodiments of the present invention;

FIG. 4 is a diagram of a web page for submitting an on-line request for account data in accordance with exemplary embodiments of the present invention;

FIG. 5 is a diagram of a web page for providing on-line account data in accordance with exemplary embodiments of the present invention;

FIG. 6 is a diagram illustrating a web page for a user to log into the system in accordance with exemplary embodiments of the present invention;

FIG. 7 is a diagram illustrating a detailed web page for submitting an on-line request for account data in accordance with exemplary embodiments of the present invention;

FIG. 8 is a diagram illustrating a web page for providing on-line account data in accordance with exemplary embodiments of the present invention;

FIG. 9 is a combination process flow chart and diagram showing the application of predefined logic in order to map hotel folio line items to more descriptive hotel folio line items accordance with exemplary embodiments of the present invention;

FIG. 10 is a combination process flow chart and system diagram of data processing and data movement for matching folios with transaction data in accordance with exemplary embodiments of the present invention; and,

FIG. 11 is a combination process flow chart and system diagram of a system and method for processing hotel folio line items to ensure proper assignment if item codes and item code descriptions in accordance with exemplary embodiments of the present invention.

DETAILED DESCRIPTION

Exemplary embodiments include a web application that enables access to a client's specific account transaction detail for the purposes of, for example, vendor negotiation and card program management. The charge transaction detail includes, for example, travel transaction detail, corporate card detail, loyalty information detail and corporate purchasing card detail. In one embodiment, the transaction detail is global in nature (e.g., data captured from all regional systems) and can include third party data regarding card, travel and hotel, as well as reference data which can be purchased from multiple industry vendor sources.

The term “charge card” is intended to include transaction cards, credit cards, debit cards, stored value cards, transponders, and non-card based financial accounts.

The web application and web page access that clients use to access the data and create report views of the information can be implemented with, for example, a third party software package called MicroStrategy from a company called MicroStrategy. The product enables clients to manage their corporate program with a host as the card provider, along with their own travel management performance and policies. In addition, the product enables the clients to negotiate purchase opportunities with key vendors (airlines, hotels etc).

The system can also include a “create a report capability” which allows users to add filters and data elements to an existing report format and create a report specific to their needs and data. The system includes access for the clients to individual market level detail, along with LAC, EMEA, and JAPA (Latin America/Caribbean, Europe, Middle East, Africa, and Japan, Asia, Pacific, Australia) transaction detail. The system also allows report generation wherein the reports include LID (line item detail) data from the clients' Corporate Purchase Card (CPC) purchases, thereby allowing the user to view specific detailed transactions from their selected vendors. This feature includes full hierarchy information and enhanced reporting capabilities. The system also includes Corporate Purchasing card data in its warehouse, which allows clients to view their total program with the host. It also allows clients to combine the data sets and have a single report generated on both CPC and Card spend. The functionality and access allows faster delivery of information to clients which results in, for example, increased client loyalty.

In an exemplary embodiment, the web application eliminates or reduces the need for any ‘helper’ applications on the web browser, provides a more scalable application and allows clients to access certain data and create report views of the information. Removal of the ‘helper apps’ (e.g., Active-X or Java Applets), in one embodiment, allows greater market penetration since these applications have been shown in some instances to be security risks. The invention also eliminates the need for a separate security log-in function and allows implementation of a single sign-on capability. As such, clients can log into a single portal and are automatically logged into applications within the portal without having to re-authenticate.

A product implementing an exemplary embodiment is a combination of function, features, data and support service. More particularly, in one embodiment, the product is accessed via a web site which is specifically focused on corporate accounts, the program administrator and the corporate card member. The database is a combination of charge card information (transactions) from every region and country that the host operates as a wholly owned organization or as a franchise or partnership. The collection, consolidation, data management and conditioning of that data are unique in several areas. The database adds and conditions data with proprietary information relating to the host supplier network. This allows the clients using the product to view and report on their corporate spend in key categories (e.g., industries). The data conditioning process for the database captures and consolidates multiple data sources from industry providers. There are also multiple airline data feeds and computerized reservation system (CRS) data feeds providing additional enriched data such as air sectors (travel itinerary) fare basis codes, etc. Many of these data feeds can be purchased by the host on behalf of the client and the data is integrated with their account data.

The client can report on this data in multiple views, either an individual country, a region, or on a global basis. The reporting functionality is also a combination of unique products and services. The tool provides a single sign on capability which allows the client to sign on once at the central web site and then access multiple services and functions, wherein one of these functions is the enhanced reporting capability. The client has the ability to view their spend via a web browser while no software is required to be loaded on the client PC. The clients have access to a set of standard reports or have the ability to develop a view of the data (report) that they request and create on-line. The reports can be viewed on-line, printed or exported into other software formats such as Excel at the client site. The charge card information is provided in, for example, two forms such as billed and unbilled; and the client can view either through the reporting tool. Additionally, the client can view their Corporate Purchase Card data and their Corporate Card charges as separate sets of data or on a combined report.

Portfolio Web Network

Practitioners will appreciate that the present invention may use any combination of proprietary and/or commercially available hardware and/or software products to carry out the process steps described herein. However, for explanation and understanding, a system diagram describing such components is disclosed. This simplified diagram describes the invention according to one embodiment where hotel folio data can be retrieved from multiple data sources, processed (as will be described in greater detail herein), and delivered to a client via the Internet.

FIG. 1 is a schematic diagram of a system 10 for providing on-line classified hotel folio data. System 10 provides daily transaction-level reports, as well as summary-level reports that are broken out by spend categories. Such reports will strengthen efforts by travel managers and Corporate Card program managers to enhance the value of their hotel programs and ensure compliance with established policies and procedures. Moreover, the reports can help companies monitor employee compliance with corporate lodging policies governing use of preferred hotels

In system 10, a user at a user computer 12 may submit an on-line request to a server computer 16, via a network 14, for charge card transaction details. Server computer 16, via a network 14, can access multiple data sources 20, 22, and 24 to obtain the hotel folio detail for the user. Once it obtains the data, server computer 16 processes, filters, and scrubs the data, as it often will be retrieved from multiple disparate sources (including any combination of internal or external data sources), and format the data into a report and/or billing statement. As will be discussed in greater detail herein, the processing of the data includes retrieving a list of hotel item codes corresponding to the source and mapping each hotel item code with a defined item code including a detailed description. Server computer 16 then sends the report to user computer 12 via network 14 in, for example, a web page or other format. Networks 14 and 18 can include any wireline or wireless network for data communication. The communication across the network may be achieved using web services technology, including but not limited to Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), or Universal Description, Discovery and Integration (UDDI). Three data sources are shown for illustrative purposes only; embodiments can include more or fewer data sources depending upon a particular implementation. The data sources 20, 22, and 24 represent any source of data such as, a local or remote memory or database, possibly in conjunction with an associated computer.

It will be appreciated, that many applications of the present invention could be formulated. One skilled in the art will appreciate that the network may include any system for exchanging data or transacting business, such as the Internet, an intranet, an extranet, WAN, LAN, satellite communications, and/or the like. It is noted that the network may be implemented as other types of networks, such as an interactive television (ITV) network. The users may interact with the system via any input device such as a keyboard, mouse, kiosk, personal digital assistant, handheld computer (e.g., Palm Pilot®), cellular phone and/or the like. Similarly, the invention could be used in conjunction with any type of personal computer, network computer, workstation, minicomputer, mainframe, or the like running any operating system such as any version of Windows, Windows NT, Windows2000, Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris or the like. Moreover, although the invention is frequently described herein as being implemented with TCP/IP communications protocols, it will be readily understood that the invention could also be implemented using IPX, Appletalk, IP-6, NetBIOS, OSI or any number of existing or future protocols. Moreover, the system contemplates the use, sale or distribution of any goods, services or information over any network having similar functionality described herein.

The computing units may be connected with each other via a data communication network. The network may be a public network and assumed to be insecure and open to eavesdroppers. In the illustrated implementation, the network may be embodied as the internet. In this context, the computers may or may not be connected to the internet at all times. For instance, the customer computer may employ a modem to occasionally connect to the internet, whereas the bank computing center might maintain a permanent connection to the internet. Specific information related to the protocols, standards, and application software utilized in connection with the Internet may not be discussed herein. For further information regarding such details, see, for example, DILIP NAIK, INTERNET STANDARDS AND PROTOCOLS (1998); JAVA 2 COMPLETE, various authors, (Sybex 1999); DEBORAH RAY AND ERIC RAY, MASTERING HTML 4.0 (1997). LOSHIN, TCP/IP CLEARLY EXPLAINED (1997). All of these texts are hereby incorporated by reference.

The systems may be suitably coupled to network via data links. A variety of conventional communications media and protocols may be used for data links. Such as, for example, a connection to an Internet Service Provider (ISP) over the local loop as is typically used in connection with standard modem communication, cable modem, Dish networks, ISDN, Digital Subscriber Line (DSL), or various wireless communication methods. Merchant system might also reside within a local area network (LAN) which interfaces to network via a leased line (T1, D3, etc.). Such communication methods are well known in the art, and are covered in a variety of standard texts. See, e.g., GILBERT HELD, UNDERSTANDING DATA COMMUNICATIONS (1996), hereby incorporated by reference.

FIG. 2 is a schematic diagram of an exemplary computer 30 illustrating typical components of the computers and server shown in FIG. 1 for the system. Computer 30 may include a connection with a network 46 such as the Internet or communications networks through any suitable network connection using, for example, TCP/IP for data transmission. Computer 30 typically includes a memory 32, a secondary storage device 40, a processor 42, an input device 36 for entering information into computer 30, a display device 38 for providing a visual display of information, and an output device 44 for outputting information such as in hard copy or audio form.

Memory 32 may include random access memory (RAM) or similar types of memory and it may store one or more applications 34 for execution by processor 42. Applications 34 may include programming to perform the methods discussed herein.

Secondary storage device 40 may include any hardware and/or software for storing data such as, for example, a hard disk drive, floppy disk drive, CD-ROM drive, or other types of non-volatile data storage. Processor 42 may execute applications or programs stored in memory 32 or secondary storage 40, or received from the Internet or other network 46. Although computer 30 is depicted with various components, one skilled in the art will appreciate that the computer may contain different components.

Computer 30 may include local or remote databases for storing and retrieving information for processing transactions. Any databases discussed herein may be any type of database, such as relational, graphical, hierarchical, object-oriented, and/or the like.

Common database products that may be used to implement the databases include UDB by IBM (White Plains, N.Y.), any of the database products available from Oracle Corporation (Redwood Shores, Calif.), Microsoft Access or MSSQL by Microsoft Corporation (Redmond, Wash.), or any other database product. The database may be organized in any suitable manner, including as data tables or lookup tables. Association of certain data may be accomplished through any data association technique known and practiced in the art. For example, the association may be accomplished either manually or automatically. Automatic association techniques may include, for example, a database search, a database merge, GREP, AGREP, SQL, and/or the like. The association step may be accomplished by a database merge function, for example, using a “key field” in each of the manufacturer and retailer data tables. A “key field” partitions the database according to the high-level class of objects defined by the key field. For example, a certain class may be designated as a key field in both the first data table and the second data table, and the two data tables may then be merged on the basis of the class data in the key field. In this embodiment, the data corresponding to the key field in each of the merged data tables is preferably the same. However, data tables having similar, though not identical, data in the key fields may also be merged by using AGREP, for example.

For the sake of brevity, conventional data networking, application development and other functional aspects of the systems (and components of the individual operating components of the systems) may not be described in detail herein. Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in a practical electronic transaction system.

The system, as shown in FIG. 1, may include a host server or other computing systems including a processor for processing digital data, a memory coupled to said processor for storing digital data, an input digitizer coupled to the processor for inputting digital data, an application program stored in said memory and accessible by said processor for directing processing of digital data by said processor, a display coupled to the processor and memory for displaying information derived from digital data processed by said processor and a plurality of databases, said databases including client data, merchant data, financial institution data and/or like data that may be used in association with the present invention. As those skilled in the art may appreciate, user computer may typically include an operating system (e.g., Windows NT, 95/98/2000, Linux, Solaris, etc.) as well as various conventional support software and drivers typically associated with computers. User computer may be in a home or business environment with access to a network. In an exemplary embodiment, access is through the Internet through a commercially-available web-browser software package.

Communication between the parties to the transaction and the system of the present invention may be accomplished through any suitable communication means, such as, for example, a telephone network, Intranet, Internet, point of interaction device (point of sale device, personal digital assistant, cellular phone, kiosk, etc.), online communications, off-line communications, wireless communications, transponder communications and/or the like. One skilled in the art may also appreciate that, for security reasons, any databases, systems, or components of the present invention may include any combination of databases or components at a single location or at multiple locations, wherein each database or system includes any of various suitable security features, such as firewalls, access codes, encryption, decryption, and/or the like.

The computers discussed herein may provide a suitable website or other Internet-based graphical user interface which is accessible by users. In one embodiment, the Internet Information Server, Microsoft Transaction Server, and Microsoft SQL Server, are used in conjunction with the Microsoft operating system, Microsoft NT web server software, a Microsoft SQL database system, and a Microsoft Commerce Server. Additionally, components such as Access or SQL Server, Oracle, Sybase, Informix MySQL, Interbase, etc., may be used to provide an ADO-compliant database management system.

The present invention may be described herein in terms of functional block components, screen shots, optional selections and various processing steps. It should be appreciated that such functional blocks may be realized by any number of hardware and/or software components configured to perform the specified functions. For example, the present invention may employ various integrated circuit components, e.g., memory elements, processing elements, logic elements, look-up tables, and the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. Similarly, the software elements of the present invention may be implemented with any programming or scripting language such as C, C++, Java, COBOL, assembler, PERL, Visual Basic, SQL Stored Procedures, extensible markup language (XML), with the various algorithms being implemented with any combination of data structures, objects, processes, routines or other programming elements. Further, it should be noted that the present invention may employ any number of conventional techniques for data transmission, signaling, data processing, network control, and the like. Still further, the invention may be used to detect or prevent security issues with a client-side scripting language, such as JavaScript, VBScript or the like. For a basic introduction of cryptography and network security, the following may be helpful references: (1) “Applied Cryptography: Protocols, Algorithms, And Source Code In C,” by Bruce Schneier, published by John Wiley & Sons (second edition, 1996); (2) “Java Cryptography” by Jonathan Knudson, published by O'Reilly & Associates (1998); (3) “Cryptography & Network Security: Principles & Practice” by William Stalling, published by Prentice Hall; all of which are hereby incorporated by reference.

As may be appreciated by one of ordinary skill in the art, the present invention may be embodied as a method, a data processing system, a device for data processing, and/or a computer program product. Accordingly, the present invention may take the form of an entirely software embodiment, an entirely hardware embodiment, or an embodiment combining aspects of both software and hardware. Furthermore, the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program code means embodied in the storage medium. Any suitable computer-readable storage medium may be utilized, including hard disks, CD-ROM, optical storage devices, magnetic storage devices, and/or the like.

The present invention is described herein with reference to screen shots, block diagrams and flow chart illustrations of methods, apparatus (e.g., systems), and computer program products according to various aspects of the invention. It may be understood that each functional block of the block diagrams and the flow chart illustrations, and combinations of functional blocks in the block diagrams and flow chart illustrations, respectively, may be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flow chart block or blocks.

These computer program instructions may also be stored in a computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flow chart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flow chart block or blocks.

Accordingly, fumctional blocks of the block diagrams and flow chart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions, and program instruction means for performing the specified functions. It may also be understood that each functional block of the block diagrams and flow chart illustrations, and combinations of functional blocks in the block diagrams and flow chart illustrations, may be implemented by either special purpose hardware-based computer systems which perform the specified functions or steps, or suitable combinations of special purpose hardware and computer instructions.

Hotel Folio Mapping

Hotel folio mapping, as described herein, has resulted in about 20% of all folio line items being reclassified according to this mapping logic. This reclassification is significant, as this number represents a very large number of transactions that would not have otherwise been precisely revealed to large corporate clients. Of this 20%, the amount of hotel folio line items that were previously classified as “miscellaneous” has been reduced by about 74%. These hotel folio line items have been successfully reclassified into more detailed item types. For example, the number of line items previously classified as “hotel restaurant & bar” that are reclassified to “room service” line items was up about 70% with the present invention. Moreover, the number of hotel folio line items classified as “other taxes” have been reduced by about 21%, which has resulted in the movement of these line items into detailed tax categories such as, for example, GST tax, PST tax, and occupancy tax.

In general, system 1000 uses programming logic to standardize item code categorization of item details across hotel chains and remaps items that are misclassified such as, for example, miscellaneous charges and tax types. The programming logic maps folio line items to the correct item code and item code description through, for example, key words/phrases in the associated merchant's item description. The logic is flexible to allow for the application of specific requirements relating to certain transactions, identified for an item code or range of item codes, for specific merchants, or for a particular market (e.g., merchant location). If, for any reason, system 1000 is not able to map line items to the correct item code, then the line item may be assigned to a “miscellaneous” category. Practitioner will appreciate that the system may report such line items to an administrator in order to attempt to manually assign a correct item code and/or modify the programming logic in order to correctly process such, line items in the future.

With reference to FIG. 9, an example is provided showing how logic is applied to map a hotel's item description and item code to a predefined new item code and item code description when reclassification of a folio item is required. When such logic is applied, the system is capable of providing a more precise item code and item code description as will be appreciated from the example provided by the figure. Practitioners will appreciate that the following description is very basic and that any number of variables may be considered according to the defined logic in order to produce the desired results.

As system 1000 processes folio data, determination is made as to whether any of the folio line items include an inaccurate or vague item code and item code description. When such folio line items are found, system 1000 processes each to reclassify them to the proper item code and item code description through mapping. To map a folio line item to an appropriate predefined item code and item code description, the system may perform an analysis of the item code applied to the folio line item by the merchant. Through such analysis, the system may determine by way of a lookup table, or any other means known in the art, the appropriate item code and corresponding item code description to apply to the folio line item.

In one embodiment, the system uses predefined logic to retrieve line items corresponding to the determined logic rules (step 900). The system may further use the predefined logic to construct a SQL query to retrieve compliant transaction records (step 905). In this example, a SQL query may be constructed as follows:

SELECT item_desc, item_code, item_code_desc FROM staging_table

WHERE item_desc=“rm serv” AND item_code=“3001” OR item_code=“5008”

Thus, execution of the above SQL query against a staging database may return one or more records with an item description of “rm serv” 915 and an item code of either “2001” or “5008” 920. Note that the retrieved item code description 925 states that the charge was for the “hotel restaurant & bar.” This description would be of little use to an accounting department of a corporation when determining compliance with company policy. For example, a corporation may issue traveling employees a per diem for meals at a hotel restaurant. However, because ordering meals by room service is generally more expensive than dining in a hotel restaurant, the corporation may not cover such expenses.

The system applies a new item code and item code description to any records that are retrieved by the SQL query (step 930). Therefore, according to this example, the new item code is “3001” and the new item code description is “room service.” With this new item code description, an organization is now able to precisely classify the expense into an appropriate category. Moreover, the new item code is in a format and value that can be used by the organization's accounting systems to properly chart the expense. Finally, mapped folio transaction items are stored in a staging database (step 950) where they may subsequently be matched with transaction information stored by the card provider (step 955).

FIG. 10 provides a high level view of the folio data retrieval and processing steps according to an embodiment of the present invention. At various intervals, a hotel folio parser 1010 receives folio data from various merchants in the form of folio data files 1005. Folio parser 1010 filters and scrubs the folio data before loading it to the folio database 1015. At regular and/or defined time intervals, the system 1000 queries folio database 1015 to detect newly added folio data. When new folio data is detected, system 1000 loads the data into a staging database (step 1020). If necessary, system 1000 further analyzes folio data to map property specific item codes and item code descriptions to more descriptive item codes and item code descriptions (step 1025) prior to loading the folio data into staging database 1030. For example, most merchants currently classify all room taxes under a very general description (e.g., “taxes”). However, most room charges include taxes at various levels (e.g., Federal, state, city, etc.). To provide the client with a more descriptive summary of room charges, system 1000 analyzes the item codes and item code descriptions and maps each of the taxes to more descriptive item codes and item code descriptions.

System 1000 further retrieves data from staging database and uses a matching algorithm to match folio data with individual financial transactions stored by the card provider (step 1035). As matches are identified, the matched folio data is moved into matched items database 1040 while matched folios are deleted from the staging database 1030. Practitioners will appreciate that the disclosed data flow and physical database structures may be supplemented with any number of databases, database tables, and configurations without departing from the scope of the invention.

With reference to FIG. 11, and according to an exemplary embodiment, the invention enables hotel folio data (folio data) capture and matching to a client's specific account transaction detail for the purposes of, for example, more efficient client accounting, spend analysis, policy enforcement, vendor negotiation, and card program management. The folio data is received in a specific file format from the merchants/hotels (step 1102), which is, in one embodiment, separate from the financial capture data. As used herein, the merchants may include a specific hotel property, a hotel chain, or any grouping or subset of hotels. As folio data is received, in one embodiment, it is consolidated across properties within a hotel chain and subjected to a series of processing (step 1104), filtering (step 1106), and scrubbing (step 1108) steps to ensure that there are no errors within the data file. Processing, filtering, and scrubbing further serves to standardize folio data across merchants, and to scrub for any data due to personal privacy concerns. Scrubbed folio data is stored in a folio database, which is an initial point of capture (step 1110). Practitioners will appreciate that the folio database may include any number of tables for storing folio data within various defined categories. Moreover, the invention contemplates the use of any number of databases, files, formats, and configurations for storing folio data retrieved from merchants.

In one embodiment, hotel folio data includes information used by the system to process the folio data such that, when required, hotel folio items may be mapped to accurate and/or more descriptive folio items. This information includes, for example, descriptors relating to the hotel type, number of days in stay, room type, various services provided by the hotel, various applicable taxes, and the like. Folio data may further include information that can be used by accounting systems to properly record folio data within the appropriate systems of an enterprise. Such data may include, for example, a reference number, item codes, item amount, as well as any other information useful in ensuring compliance with an organization's accounting systems and policies.

According to one embodiment, folio data from various merchants may be captured throughout a defined time period. At a predetermined time, data captured during the previous time period is moved to a staging database (step 1112). However, if it is determined that one or more folio line items does not include an accurate item code and item code description (step 1112), then the system maps the one or more items (step 1114) as described in reference to FIG. 9. Folio line items that have been mapped along with folio line items not requiring mapping are moved to a staging database (step 1116).

The system processes data in the staging database to attempt to match each hotel folio data record against an original charge transmission. The system 1000 establishes matches by analyzing, for example, the card number and transaction information (step 1118). The process may continue to attempt to match the folio data to an original charge transmission for a pre-determined amount of time. If the folio data is matched, then the matching transaction identifiers are captured and the data is loaded to a matched items database for client reporting (step 1120).

In one embodiment, the system 1000 facilitates the collection of transactional data from various sources, conditioning, and combining the information into a meaningful report and/or billing statement, and issuing the report/statement to a corporate client through an online interface. In addition to reporting spends, the system reports on information from various other sources such as a hotel. Because spend transactions (card side) are matched up and reported with vendor information (supplier side); a user is able to determine the volume of spend based on some very specific parameters. For example, a user could use the system to determine how much spend resulted from cancellation fees for rooms that were reserved in New York City over a given period of time. The system architecture collects this data from many different sources and in many different forms, conditions the data so that it is all in the same format, and matches hotel folios with specific spend transactions.

Practitioners will appreciate that the system may capture folio data by any means known in the art including, for example, real-time and batch mode. According to one embodiment, each hotel property is responsible for transmitting the folio data file to the system at regular time periods, defined time periods, upon the occurrence of an event, after a certain number of transactions and/or the like.

In an exemplary embodiment, the hotel folio data is global in nature (e.g. data captured from all regional systems) and can include third party data regarding both card and reservation, as well as reference data which can be purchased from multiple industry vendor sources. The web application and webpage access that clients use to access the data and create report views of the information is, for example, a third party software package. The product enables clients to manage their corporate program with a host as the card provider, along with their own travel management performance and policies. In addition, the product enables the clients to negotiate purchase opportunities with key vendors (airlines, hotels etc).

According to one embodiment, the system may calculate and issue reward or loyalty points based on the processing steps described above. In performing an analysis of a merchant's item codes, the system may determine, for example, that the cardholder's spend on meals fell bellow the allowed per diem, and issue a number of reward points to the card holder based on the summed savings. Such points may be applied to a card holder account according to rules defined by the master account holder (e.g., corporation). For example, in order to encourage employees to stay in economy hotels, a corporation may award a number of reward points to the card holder for personal use. The transaction card issuer, the hotel, or any other merchant may also award loyalty points to the customer, employer, hotel or any other entity or person.

Portfolio Reporting

FIG. 3 is a flow chart of an exemplary method 50 to provide on-line account data, which may include card data. Method 50 may be implemented in, for example, software modules for execution by user computer 12 and server computer 16. Although the steps of method 50 are shown in a particular order, they may alternatively be executed in other orders and more steps may be added or steps removed, if necessary or desired.

In method 50, server computer 16 receives a request from a user at user computer 12 for account data (step 52). The “account data” can include any data related to transactions involving credit cards, charge cards, or other financial cards. In one embodiment, account data may include, for example, hotel folio data. User computer 12 may include, for example, a software application to help facilitate the user's communication with server computer 16. The request may be received from a user or other person, for example, at the requesting entity. As used herein, the term “end user”, “consumer”, “customer”, “supplier”, “cardmember”, “business” or “merchant” may be used interchangeably with each other, and each shall mean any person, entity, machine, hardware, software or business. The card issuing institutions may include credit card companies, card sponsoring companies, or third party issuers under contract with financial institutions. It is further noted that other participants may be involved in some phases of the transaction, such as an intermediary settlement institution, but these participants are not shown.

FIG. 4 is a diagram of an exemplary screen 70 for a user to enter a request for account data and submit it to server computer 16. FIGS. 6 and 7 illustrate examples of more detailed screens for a user to log into the system and submit an on-line request for account data.

Screen 70 can be implemented in, for example, a web page for network transmission. The term “web page” as it is used herein is not meant to limit the type of documents and applications that might be used to interact with the user. For example, a typical website might include, in addition to standard HTML documents, various forms, Java applets, JavaScript, active server pages (ASP), common gateway interface scripts (CGI), extensible markup language (XML), dynamic HTML, cascading style sheets (CSS), helper applications, plug-ins, and the like. A server may include a webservice which receives a request from a browser which includes a URL and an IP address (e.g., 127.0.0.1). The webservice retrieves the appropriate web pages and sends the web pages to the IP address.

In screen 70, a user can enter a user name or other identifier in a section 72 and a password in a section 74. A section 76 allows a user to enter a particular query, which can include a request for account data within certain parameters, examples of which are provided above. The user can select a section 78 to submit the request or select a section 80. to cancel the request.

The request may optionally include an account number. An “account number”, as used herein, may include any device, code, number, letter, symbol, digital certificate, smart chip, digital signal, analog signal, biometric or other identifier/indicia suitably configured to allow the consumer to interact or communicate with the system, such as, for example, authorization/access code, personal identification number (PIN), Internet code, other identification code, and/or the like which is optionally located on a rewards card, charge card, credit card, debit card, prepaid card, telephone card, smart card, magnetic stripe card, bar code card, transponder, radio frequency card and/or the like. The account number may be distributed and stored in any form of plastic, electronic, magnetic, radio frequency, wireless, audio and/or optical device capable of transmitting or downloading data from itself to a second device. A customer account number may be, for example, a sixteen-digit credit card number, although each credit provider has its own numbering system, such as the fifteen-digit numbering system used by American Express. Each company's credit card numbers comply with that company's standardized format such that the company using a sixteen-digit format may generally use four spaced sets of numbers, as represented by the number “0000 0000 0000 0000”. The first five to seven digits are reserved for processing purposes and identify the issuing bank, card type and etc. In this example, the last sixteenth digit is used as a sum check for the sixteen-digit number. The intermediary eight-to-ten digits are used to uniquely identify the customer.

After receiving the request, server computer 16 polls or otherwise contacts data sources 20, 22, and 24 to obtain the account data for the user's request (step 54). Server computer 16 conditions the data and can store it (step 56). Server computer 16 can use, for example, metadata in order to determine how to locate and retrieve the account data. In particular, a relationship can be defined between the query (request) attributes and metrics, and target data sources to assure the integrity of the account data report returned to the user.

Server computer 16 also determines if the user's request includes a query, as represented in section 76 of screen 70 (step 58). If the request does not include a query, server computer 16 can format the conditioned data into a standard or default report (step 60). If the request included a query (step 58), server computer 16 processes the query to extract the relevant data satisfying the query parameters (step 62). A query, as submitted by a user, can include a request for account data satisfying certain parameters. Processing the query can include parsing the natural language submitted query to generate search parameters. Those parameters can be used to obtain the relevant data using, for example, the metadata. Server computer 16 can format the extracted data into a custom report (step 64). Once the report is compiled and formatted, server computer 16 can send the standard or custom report to user computer 12 via network 14 (step 66).

FIG. 5 is a diagram of an exemplary screen 82 for providing on-line account data. FIG. 8 illustrates an example of a more detailed screen for providing on-line account data. Screen 82 can be implemented, for example, in a web page for network transmission. Screen 82 can include a section 84 for providing the report details and can optionally include a section 86 to repeat the user's query, if one was submitted.

Benefits, other advantages, and solutions to problems have been described herein with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any or all the claims or the invention. As used herein, the terms “comprises”, “comprising”, or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, no element described herein is required for the practice of the invention unless expressly described as “essential” or “critical”.

The detailed description of exemplary embodiments of the invention herein makes reference to the accompanying drawings and pictures, which show the exemplary embodiment by way of illustration and its best mode. While these exemplary embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, it should be understood that other embodiments may be realized and that logical and mechanical changes may be made without departing from the spirit and scope of the invention. Thus, the detailed description herein is presented for purposes of illustration only and not of limitation. For example, the steps recited in any of the method or process descriptions may be executed in any order and are not limited to the order presented. 

1. A computer implemented method for providing a user with on-line financial account data based on folio data, said method including: receiving, at said host computer, a folio file from an external source, wherein said folio file comprises folio data items; and, processing, at said host computer, said folio data items to map one of said folio data items with an item code, wherein said item code includes a corresponding item code description.
 2. The method of claim 1, further including receiving from a user, at said host computer, a request for financial account data.
 3. The method of claim 1, wherein said receiving step includes receiving said folio file from the multiple sources in disparate formats.
 4. The method of claim 1, further including formatting, at said host computer, said folio data, wherein said formatting includes converting a plurality of said folio files from disparate formats into a single format.
 5. The method of claim 1, further including filtering, at said host computer, said folio data, wherein said filtering includes analyzing said folio data to identify data errors.
 6. The method of claim 1, further including scrubbing, at said host computer, wherein said scrubbing includes removing a subset of said folio data that is determined to be private.
 7. The method of claim 1, further including conditioning, at said host computer, wherein said conditioning includes consolidating said folio data across properties within a hotel chain.
 8. The method of claim 1, further including organizing said financial account data into at least one of a billing statement and a report.
 9. The method of claim 2, further including: receiving from said user a query associated with said request; invoking said query to retrieve said financial account data in accordance with parameters of said query; and, sending said retrieved financial account data on-line to said user.
 10. The method of claim 1, further including issuing reward points based on at least one of: said folio data items and said item code.
 11. The method of claim 1, further including matching each of said folio data items to a corresponding spend transaction according to at least one of card number, transaction date, service establishment number, and transaction amount.
 12. The method of claim 1, further including moving said folio data items from a first database to a second database when said item code matches one of said folio data items.
 13. The method of claim 12, wherein said second database includes tables for storing at least one of: folio record, folio tax summary, folio item, and folio payment.
 14. The method of claim 1, further including analyzing said folio data to determine when a change is required to at least one of: said item code and said item code description.
 15. The method of claim 1, wherein said host computer includes database tables for storing at least one of: said folio file, folio record, folio tax summary, folio item, and folio payment
 16. The method of claim 1, wherein folio data includes at least one of: descriptors relating to hotel type, number of days in stay at hotel, room type, services provided by hotel, and applicable taxes.
 17. The method of claim 1, wherein said folio data includes accounting data comprising at least one of: item sequence number, item reference number, item code, internal item descriptor, item category code, item category descriptor, item descriptor, item amount, item date, taxable amount, and tax exempt indicator.
 18. The method of claim 1, wherein said folio data includes third-party data relating to reference data that is at least one of: obtained and purchased from a plurality of vendor sources.
 19. The method of claim 2, wherein said request includes at least one of: said item code, said item code description, range of item codes, range of item code descriptions, merchant identifier, and market identifier.
 20. The method of claim 1, wherein said processing step includes mapping said one of said folio data items with an item code by using previously established database records.
 21. The method of claim 1, wherein said processing step includes mapping one of said folio data items with an item code by using previously established database records in a look-up table.
 22. The method of claim 1, wherein said processing step includes matching by using previously established database records, wherein said previously established database records were created by. receiving, at a host computer, a merchant item code from a merchant, wherein said merchant item code includes an item code description; retrieving, at said host computer, an item code corresponding to said merchant, wherein said item code includes an item code description; mapping, at said host computer, said merchant item code to said item code to create said database.
 23. The method of claim 1, further including conditioning, at said host computer, said folio data, wherein said conditioning includes at least one of formatting, filtering, and scrubbing.
 24. The method of claim 1, further including: receiving, at said host computer, an on-line request from said user for financial account data, wherein said financial account data includes a subset of said folio data items; conditioning, at said host computer, said financial account data to create said online financial account data for transmission to said client computer; and, sending said online financial account data to said user.
 25. A computer implemented method for a user receiving on-line financial account data based on folio data, said method including: requesting, by said user, said on-line financial account data based on said folio data; causing said host computer to obtain a folio file from an external source, wherein said folio file comprises folio data items; causing said host computer to process said folio data items to map one of said folio data items with an item code to obtain on-line financial account data, wherein said item code includes a corresponding item code description; and, receiving, by said user, said on-line financial account data from said host computer.
 26. A computer readable storage medium containing a set of instructions for a general purpose computer for providing a user with on-line financial account data based on hotel folio, said instructions including: receiving, at said host computer, a folio file from an external source, wherein said folio file comprises folio data items; and, processing, at said host computer, said folio data items to map one of said folio data items with an item code, wherein said item code includes a corresponding item code description. 